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ABSTRACT 

The  development  of  Operational  Requirements  (OR)  for  military  platforms  is  a  complex  and  tedious  task, 
for  which  many  aspects  need  to  be  addressed  (integral)  and  for  which  few  tools  are  available.  This  task  is 
usually  performed  by  temporary  placed  military  personnel  trying  their  best  to  deliver  a  list  of  relevant  OR. 
The  RNLA  has  a  need  for  a  methodical  approach  and  associated  tools,  providing  a  means  to  enhance  the 
quality  but  also  the  re-use  of  OR.  Key  is  an  integral  approach  not  only  aimed  at  the  functionality  of  the 
platform  but  also  at  the  crew  and  many  other  relevant  and  interacting  viewpoints. 

The  paper  gives  a  description  of  the  process  to  arrive  at  a  set  of  operational  requirements  and  a 
description  of  the  tools  that  may  be  used  to  support  the  process.  A  distinction  is  made  between  new  OR  for 
systems  and  mid-life  upgrades  and  mission  dependent  add-ons.  Fictitious  examples  are  given  in  the 
description  and  explanation. 


1.0  BACKGROUND 

The  research  project  ‘Integral  Analysis  of  Platform  Performance’  (IAPP)  aims  at  the  analysis  of  platform 
performance  from  an  integral  point  of  view.  In  the  project  a  method  has  been  derived  to  answer  questions 
related  to  the  performance  of  RNLA  platforms  (land,  sea  or  air).  Until  recently  detailed  performance 
analysis  was  done  on  different  disciplines  in  separate  lanes.  The  influence  and  effect  of  disciplines  on  each 
other  was  not  taken  into  account  which  sometimes  led  to  unwanted  results.  A  systems  engineering 
approach  has  been  chosen  to  include  different  disciplines  and  to  consider  a  platform  from  many  different 
viewpoints.  To  address  performance  analysis  in  an  integral  way  as  many  aspects  as  are  necessary  need  to 
be  considered,  given  the  question  at  hand. 

The  IAPP  method  is  based  on  a  four  level  approach.  The  levels  vary  in  detail  and  differ  in  integrality.  Two 
levels  are  based  on  the  use  of  expert  knowledge  and  two  levels  are  based  on  the  use  of  modelling, 
simulation  and  experimentation. 

The  IAPP  method  has  been  tried  out  in  a  case  study.  The  case  comprised  a  fictitious  platform  which 
needed  to  be  compared  to  some  alternative  existing  platforms.  To  be  able  to  compare  the  systems,  a  set  of 
characteristics  and  operational  requirements  were  defined  for  the  fictitious  platform.  During  this  process 
several  tools  were  created  and  used.  The  case  has  been  shown  to  RNLA  staff,  resulting  in  formalisation  of 
the  used  method  and  tools  and  start  of  a  software  implementation.  Software  tools  are  currently  under 
development. 

The  tools  comprise  a  set  of  libraries  containing  many  aspects  denoting  different  viewpoints.  Each  aspect 
system  is  a  hierarchical  subdivision  (tree)  of  a  specific  main  aspect  build  from  a  certain  view  on  the 
system.  A  system  function  tree  is  one  of  the  important  aspect  systems.  Other  main  aspect  systems  include 
environmental  aspects,  target  types,  platform  types  and  threat  types. 
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2.0  DEVELOPMENT  OF  OPERATIONAL  REQUIREMENTS 

Operational  requirements  describe  what  the  RNLA  expects  of  a  platform.  They  describe  what  a  platform 
should  be  able  to  do,  to  perform.  The  process  to  come  to  operational  requirements  is  complex.  Many 
aspects  need  to  be  addressed  during  different  phases.  Each  phase  building  upon  the  previous  one,  detailing 
requirements  and  solutions.  We  address  the  phase  where  the  type  of  platform  has  already  been  decided  and 
further  operational  requirements  need  to  be  written.  The  method  to  support  the  development  of  operational 
requirements  helps  to  address  the  many  aspects  in  a  methodical  way,  providing  access  to  an  extensive  list 
of  aspects. 

Figure  2  shows  an  IDEFO  process  schema  of  the  method.  Figure  1  gives  an  explanation  of  the  elements  in 
the  IDEFO  schema. 


Figure  1 :  Explanation  of  IDEFO  process. 

The  process  starts  with  the  formulation  of  the  needed  defence  capacity.  The  military  need  (the  capability 
gap)  is  the  input  and  platform  type  restricts  the  type  of  capacity.  In  the  process  the  tasks  and  environment 
are  also  formulated.  They  act  as  constraints  on  the  subsequent  process  steps.  With  the  ‘defence  capacity’  a 
selection  is  made  of  the  aspects  that  are  relevant  for  the  capacity.  The  selected  aspects,  the  defence 
capacity  and  tasks  &  environment  restrictions  are  used  to  generate  a  system  tree.  The  system  tree  nodes 
are  then  visited  and  attributes  are  collected,  followed  by  entering  normative  values  for  the  system  node 
attributes.  Finally  the  results  are  stored  as  Operational  Requirements. 
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Figure  2:  IDEFO  process  schema  of  the  support  method. 


2.1  Describe  required  defence  capacity 

The  first  step  is  to  determine  what  defence  capacity  is  required.  Defence  capacity  is  aimed  at  carrying  out 
defence  tasks. 

A  defence  capacity  can  be  described  as  follows: 


the  platform  should  be  able  to  do  XYZ  /  deliver  KLM  effects,  in  compliance  with  constraints  ABC 


Aspects  support  the  formulation  of  XYZ,  KLM,  ABC  and  norms  with  respect  to  XYZ,  KLM  and  ABC. 
Aspect  checklists  enable  selection  of  relevant  aspects.  Some  aspects  are  strongly  related  to  the  primary 
functions  of  the  RNLA.  Other  aspects  are  related  to  secondary  functions  and  usage,  and  some  aspects  act 
as  constraints  which  the  platform  has  to  comply  with. 

The  defence  capacity  determines  what  tasks  need  to  be  carried  out,  in  what  environments  and  what  effects 
are  to  be  addressed.  There  are  no  predefined  capacities  in  the  libraries. 

Defence  capacity  should  be  formulated  in  terms  of  functional  aspects.  Anti-tank  capacity  can  be 
formulated  in  terms  of  targets,  i.e.  tanks,  environment,  e.g.  range,  cultivation,  e.g.  urban,  climates,  e.g. 
arctic,  geographic  locations,  etc.  which  pose  additional  constraints  with  respect  to  the  formulation  of  OR. 

2.2  Describe  what  tasks  need  to  be  carried  out 

One  step  is  to  describe  what  tasks  are  to  be  carried  out  by  the  system.  Tasks  describe  what  a  system  is 
used  for.  Tasks  may  be  described  in  many  ways,  and  address  different  levels  of  detail. 
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Military  tasks  are  classified  in  a  limited  number  of  classes,  each  with  their  specifics.  Task  descriptions 
need  to  be  on  platform  level,  and  platforms  need  to  be  able  to  carry  out  the  tasks.  There  is  no  advantage  in 
describing  them  on  other  levels.  The  majority  of  tasks  can  be  done  as  a  combination  of  the  following 
system  (platform)  tasks: 

•  manoeuvre; 

•  protect; 

•  observe; 

•  communicate; 

•  bring  out  effect. 


2.3  Determine  what  environments  will  be  addressed 

Several  aspects  are  addressed  in  the  environmental  aspects.  They  comprise  climate,  geographic  location, 
area  cultivation  (green  field,  urban,  woods,  planar  . . .),  weather  and  last  but  not  least  target  types. 

Environmental  aspects  introduce  variations  in  variables  which  influence  system  performance.  For  climatic 
and  geographic  environments  associated  physical  parameters  such  as  humidity,  temperature,  atmospheric 
pressure  influence  physical  performance  of  components  of  the  system.  And  operations  in  urban 
environments  pose  restrictions,  for  example,  on  barrel  length  and  elevation  possibilities. 

Humidity  and  atmospheric  pressure  for  instance  influence  engine  power  /  engine  performance.  The  lower 
the  pressure,  the  less  power  is  generated  and  the  less  the  engine  performs.  In  high  countries  with  low 
atmospheric  pressure  system  performance  reduces  because  of  the  reduction  in  engine  power. 
Environmental  aspects  assist  the  OR  developer  to  think  about  these  influences. 

The  other  environmental  aspect  addresses  expected  target  systems.  Different  targets  have  different 
characteristics  requiring  different  degrees  of  loads  and  damage  mechanisms.  They  react  differently  to 
similar  degrees  of  load  and  the  results  of  attack  generate  different  effects  on  e.g.  insurgents  and  own 
people.  A  distinction  is  therefore  made  between  infrastructural  targets,  personnel  targets  and  equipment 
targets.  To  injure  personnel  targets  an  anti-tank  weapon  is  clearly  overkill.  A  capacity  to  eliminate  a  tank 
however  needs  a  similar  capacity  as  an  anti-tank  system.  A  similar  reasoning  can  be  set  up  for 
infrastructural  targets. 

2.4  Determine  what  aspects  and  aspect  systems  will  be  addressed 

The  aspect  library  assists  in  signifying  relevant  aspects.  The  aspect  library  contains  collected  aspect 
systems  and  characteristics  which  describe  each  aspect,  characterise  it  and  value  it.  Aspect  systems, 
individual  aspects  and  sub  aspects  may  be  selected.  The  OR  developer  is  encouraged  to  think  about  shown 
characteristics  and  decide  on  possible  values. 

The  aspect  systems  comprise  a  range  of  viewpoints.  Viewpoints  concerning  functionality,  but  also 
viewpoints  concerning  political  impact  of  a  system.  The  life -cycle  of  a  system  is  taken  into  account  and 
other  logistics  aspects. 

2.5  Generate  system  trees 

A  system  is  a  set  of  elements  and  the  relations  between  those  elements,  and  is  determined  by  a  viewpoint. 
A  generic  system  tree  is  based  on  a  functional  viewpoint  and  contains  functional  components  and 
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subsystems.  Each  system  node  can  be  considered  a  component  (no  further  breakdown  needed  or  possible) 
or  a  subsystem  fulfilling  a  specific  function.  A  system  node  contains  characteristics  which  describe  the 
component.  The  characteristics  are  used  for  registration  of  operational  requirements.  The  generic  system 
tree  contains  many  functional  subsystems  and  components  which  may  fulfill  a  range  of  functions.  Some 
examples  are: 

•  mobility  system 

The  mobility  system  contains  all  components  and  subsystems  responsible  for  moving  the  platform.  A  land 
platform  e.g.  contains  the  propulsion  system  with  engine,  propulsion,  suspension,  tracks  or  wheel.  For  a 
sea  platform  it  does  not  contain  suspension,  tracks  or  wheels,  but  includes  screw  and  screw  axes. 

•  firepower  system 

The  firepower  system  contains  weapon  systems  belonging  to  a  platform.  For  instance  the  main  gun  of  a 
main  battle  tank,  the  coaxial  gun  for  close  combat  and  the  weapon  systems  in  use  by  personnel  inside  and 
outside  the  platform.  Target  acquisition  systems  also  play  a  role  in  the  protection  system. 

•  protection  system 

The  protection  system  can  work  passively,  actively  and  re-actively.  Also  systems  that  reduce  a  platform 
signature  are  counted  to  the  protection  system. 
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Figure  3:  Example  of  parts  of  the  generic  system  tree. 


•  communication  system 

The  communication  system  contains  all  components  that  enable  communication  with  higher  and  lower 
echelons  and  the  system  internal  communications. 

•  transport  system 
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The  transport  system  contains  platform  elements  which  are  related  to  transporting  people  and  goods.  For 
instance  loading  space  for  transport  of  munition,  personnel  space  for  transport  of  military  personnel, 
supportive  means  such  as  ramps,  winches  and  tow  cables  to  transport  other  platforms. 

Note:  The  selected  elements  themselves  are  part  of  the  operational  requirements. 

The  selected  task  and  environmental  aspects  act  as  a  filter  on  the  generic  system  tree.  The  relevance  of  a 
specific  system  for  the  selected  environments  and  tasks  determine  whether  a  system  is  used  in  the 
generated  system  tree.  A  sea  platform  does  not  need  wheels  or  tracks,  but  screws.  And  the  generated 
system  is  an  aid  to  the  OR  developper  as  well.  It  provides  a  check  list  of  components  on  what 
requirements  need  to  be  posed. 

To  generate  a  system  tree  the  libraries  are  searched  to  detect  subsystems  and  components  which  are  suited 
to  perform  the  selected  tasks.  With  the  selected  systems  each  node  provides  a  set  of  related  characteristics, 
with  which  the  various  node  functions  and  components  can  be  further  specified  and  with  which  the  OR 
developer  is  able  to  indicate  the  detailed  requirements. 

As  an  example  consider  the  following  situation.  One  of  the  systems  needed  for  an  observation  task  is  a 
sensor  system.  If  required  target  systems  include  personnel,  and  the  relative  distance  is  short,  there  is  no 
need  for  a  long-range  sensor  system.  Therefore  the  generated  system  tree  will  not  include  such  system. 

2.6  Enter  what  attributes  need  to  be  addressed 

System  tree  nodes  contain  sample  characteristics.  The  set  of  characteristics  is  used  to  fully  specify  the 
subsystem/component.  Only  relevant  characteristics  are  used  in  a  specific  situation. 

For  selected  characteristics  normative  values  are  entered.  Filling  in  attribute  values  further  registrates 
requirements.  Attribute  and  attribute  values  are  the  performance  parameters  of  the  system  under 
consideration. 


characteristic 

dimension 

range 

[m],  [m] 

minimal  target  size  -  distance  profile 

[m]  x  [m] 

frequency  range 

[Hz]  -  [Hz] 

zoom  range 

[m]  -  [m] 

angle  of  sight 

[rad] 

user  friendliness 

#  buttons; 

#  acts; 

sight  conditions 

light,  dark,  smoke,  etc. 

sensitivity  to  surroundings 

interference 

sensitivity  to  terrain 

sensitivity  to  weather 

e.g.  min.  80%  of  nominal  performance  in  rainy  conditions; 
min.  50%  of  nominal  performance  in  snowy  conditions; 

sensitivity  to  climate 

detectability 

sensitivity  to  pressure  (height,  depth) 

[kPa]  -  [kPa] 

supportability 

#  parts; 

mean  repair  time; 

complexity  of  repair,  e.g.  number  of  components  to  handle; 

load  to  surroundings 

dangerous  goods;  toxics 

Table  1  Example  characteristics  of  observation  systems. 


12-6 


RTO-MP-SAS-080 


Methodical  Support  for  Development  of  Operational  Requirements 


2.7  On  mission  dependent  add-ons  and  mid-life  upgrades 

Mission  dependent  add-ons  and  mid-life  upgrades  assume  an  existing  platform.  New  and  changed 
requirements  need  to  consider  the  existing  platform.  Fulfilling  the  requirements  is  constrained  by  the 
characteristics  of  the  existing  system. 

Mid-life  upgrades  have  a  permanent  character  and  are  aimed  at  foreseen  future  use  of  the  vehicle.  Usually 
higher  reguirements  are  requested.  When  a  weight  margin  was  introduced  during  the  design  of  the  original 
vehicle,  it  might  be  consumed  by  the  mid-life  upgrade.  However  in  practice  careful  balancing  will  be 
required  to  fulfill  the  requirements  within  the  weight  ‘budget’.  When  a  vehicle  has  been  designed  with 
future  enhancements  in  mind,  options  might  be  available  to  increase  the  weight  margin,  most  likely 
challenging  the  financial  ‘budget’. 

Mission  dependent  add-ons  are  temporary  adaptations  that  are  expected  to  give  more  options  to  fulfill  the 
current  requirements.  For  instance,  additional  protection  against  anti-tank  weapons,  which  increases  the 
weight,  can  be  applied  at  the  cost  of  a  weight  reduction  in  some  other  area,  always  considering  operational 
context. 

An  important  aspect  system  in  this  context  is  the  ‘balancing  factors’  aspect  system.  It  includes  aspects  that 
act  as  constraints  within  a  platform,  such  as  weight  and  cost.  The  aspects  mentioned  usually  are  restricted 
by  a  certain  budget,  e.g.  maximum  weight.  Adding  weight  then  to  a  subsystem  needs  to  be  compensated 
by  reducing  weight  in  another  subsystem.  Balancing  between  requirements  and  solutions  will  always  be  a 
compromise.  The  OR  development  support  tool  is  helpful  in  that  it  contains  a  set  of  balancing  aspects 
which  are  included  in  the  OR  development  process. 
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3.0  SOFTWARE:  OR  DEVELOPMENT  SUPPORT  TOOLS 
3.1  Development  of  operational  requirements 
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Figure  4:  System  overview  of  support  tool. 


To  support  the  process  a  software  tool  is  currently  under  construction.  The  tool  contains  libraries  with 
predefined,  generic  systems,  tasks,  aspects,  environments  and  system  characteristics.  Figure  4  shows  the 
systems  architecture  for  the  support  software.  Part  1  takes  care  of  interaction  with  the  user.  Part  2  is  the 
data  store  where  input,  selections  and  resulting  information  is  stored.  Part  3  comprises  the  tools  which 
support  the  process,  such  as  selector  for  aspects,  generator  for  system  tree  and  editors  for  adaptation  of 
characteristics  and  the  actual  Operational  Requirements.  Interaction  of  the  tools  with  the  libraries  takes 
place  in  part  4  and  part  5  contains  the  libraries.  Some  screen  shots  of  examples  have  been  added: 
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Figure  5:  Screenshots  examples  of  support  tool. 


3.2  Balancing  operational  requirements 

A  system  analysis  tool  (figure  6)  is  being  developed  to  investigate  the  consequences  of  changed 
requirements  to  existing  vehicles.  Requirements  changes  are  restricted  to  the  application  of  new 
technologies.  The  consequence  of  selecting  a  particular  solution  is  determined  in  an  integral  way,  showing 
the  effects  on  e.g.  mobility,  lethality  and  survivability.  Balancing  aspects  weight,  action  range  and 
available  space  are  used  to  integrally  optimise  a  vehicle. 


Figure  6:  Interface  of  the  system  analysis  tool. 
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4.0  CONCLUSION  AND  FUTURE  WORK 

A  method  has  been  introduced  to  support  an  integral  approach  to  the  development  of  Operational 
Requirements.  An  integral  approach  means  that  OR  are  introduced  for  many  aspects,  sometimes  resulting 
in  conflicting  requirements.  For  instance  requirements  on  low  infrared  signature  in  arctic  environments 
might  conflict  with  the  need  for  sufficient  heating  and  ventilation  for  the  platform  crew.  Conflicting 
requirements  usually  introduce  extra  work  and  anomalies  in  design.  And  platform  size  restrictions  might 
conflict  with  necessary  space  for  personnel. 

The  method  is  currently  under  evaluation.  Although  we  expect  to  increase  the  quality  of  future  OR 
because  of  the  integral  approach  further  investigations  and  testing  of  the  method  and  the  tools  are 
necessary.  These  topics  may  be  reported  in  future  publications. 

For  the  description  of  military  platforms  a  lot  of  restrictions  are  being  posed  upon.  A  long  list  of 
STANAGS  and  other  standardisations  are  used  during  the  specification  of  a  platform.  A  future 
development  is  to  enable  on-line  querying  of  these  standards,  rules  and  regulations.  A  subsequent  step  is 
the  evaluation  of  requirements  against  the  standards. 

A  future  application  of  the  system  analysis  tool  is  to  investigate  future  vehicle  improvements.  Conflicting 
situations  can  be  uncovered  and  using  sensitivity  analysis  requirements  for  development  can  be 
determined.  A  strong  interaction  with  the  armed  forces  is  needed  to  account  for  foreseen  or  desired 
changes  in  missions  and  consequential  changes  in  requirements. 
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